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(54) Securing electronic transactions over public networks 



(57) An electronic message for transmission over a 
network, such as the Internet, is created by encrypting 
a first component with a first crypto-key, which is asso- 
ciated with a first network entity, such that the encrypted 
first component can be decrypted by only the first net- 
work entity. The first crypto-key could, for example, be 
a symmetric crypto-key known only to the first network 
entity or the public non-symmetric crypto-key of a pri- 
vate-public non-symmetric key pair, where the private 
non-symmetric crypto key is known only to the first net- 
work entity. A second component, which is different than 



the first component, is encrypted with a second crypto- 
key, which is associated with a second network entity, 
such that the encrypted second component can also be 
decrypted by the first network entity. The second crypto- 
key could, for example, be a symmetric crypto-key 
known to both the first and second network entities or 
the private non-symmetric crypto-key of a private-public 
non-symmetric key pair of the second network entity, 
where the public non-symmetric crypto key is known to 
the first network entity. The encrypted first and second 
components are combined to create the electronic mes- 
sage. 



CM 
< 

O) 
LO 
LO 



Encrypted HTML Channel 125A Protocol Channel 130 




Protocol Channel 135A-C 



Provice Bill Summary 
& Encrypted. Signed. 
Extended UHL'S and 
Encrypted and Sicned 
Relationship 
Certificate and Encrypted. 
Sicned Voucher Record 



Browser 



Provide Bill Summary 
& Encrypted. Signed, 
Extende i URL'S & 
Encrypted and Signed 
Relationship Certificate 



Authenticate 

User A 
\ 



Encrypted. Signed 
Voucher Record 

r~ 



PtoviJe Bill Summary 



Bill Summary Information 
& Encrypted, Signed. 
Ei tended URL'S 



Encrypted. Signed 
Relationship Certification 



SCO 



110A-C 



8:11 en 
AC 



Encrypted and j— 
Sigred Extended 
URL'S 



320A-C 



Bill Detail 
Information 



Encrypted. Signed, 
Eitended URL'S to 
Bit) Detail Information 

1 

700 



CL 
LU 



FIG. 6 



Printed by Jouva, 75001 PARIS (FR) 



EP1 111 559 A2 



Description 

Cross Reference to Related Applications 

s [00011 This application is related to pending Application Serial Number 09/017,169, filed February 2, 1998, entitled 
-Distributed Data Accessing Technique 1 '; pending Application Serial Number 09/237,657, filed January 27, 1999, en- 
titled "A Technique for Centrally Tracking Transactions in an Electronic Billing System"; pending Applicatton Serial 
Number 09/301 068, filed April 28, 1999, entitled "An Electronic Bill Presentment Technique With Enhanced Biller 
Control"- pending Application Serial Number 09/414,731 , filed October 8, 1 999, entitled "Electronic Billing With Flexible 

w Biller Controlled Electronic Bill Presentment"; pending Application Serial Number 09/387,764, filed September 1 , 1 999, 
entitled "Electronic Billing With Updateable Electronic Bill Summary"; pending Application Serial Number 09/208,998, 
and filed December 11,1 998, entitled Technique for Conducting Secure Transactions Over a Network"; pending-Ap- 
plication Serial Number 09/298,889, filed April 26, 1999, entitled "Electronic Bill Presentment and/or Payment Clear- 
inghouse"; pending Application Serial Number 09/229,1 02, filed April 26, 1 999, entitled "Cashless Transactions Without 

is Credit Cards, Debit Cards or Checks", 

Technical Field 

[0002] The present invention relates generally to electronic commerce and more particularly to securing electronic 
20 transactions made over public networks such as the Internet. 

Background Art 

[0003] The Internet has had a profound affect on various aspects of everyday commerce, More and more individuals 
25 are utilizing the Internet to electronically perform tasks which were previously performed in other ways. For example, 
electronic transactions are now commonplace on the Internet. Such transactions include electronic banking, electronic 
bill presentment, electronic bill payment and electronic purchasing. 

[0004] As the use of the Internet for electronic commerce has developed, a model has emerged in which users often 
access other entities on the Internet through a trusted entity such as a financial institute. These entities through which 

30 access to other entities is made will hereinafter be referred to as "portals". 

[0005] The portals are often supported by a service provider. The service provider, for example, may process elec- 
tronic user requests, which are received by the portal, for information relating to a user's deposit account at a particular 
bank by electronically accessing information maintained by the applicable bank and processing that information so 
that it can be presented to the requesting user in a user friendly form. 

35 [0006] Similarly, the service provider may also be the entity which responds to user requests received by the portal 
for billing information. For example, the service provider may receive summary bill information from numerous billers 
for numerous users and process this information such that the appropriate information can be presented in a user 
friendly manner in response to a request for bill information submitted by the user to the portal. However, if the user 
desires more detailed billing information, it is often preferable for the detailed bill information to be provided to the 

40 requesting user directly by the biller rather than by the service provider through the access portal. 

[0007] Security of network communications relates to various aspects of protection. These include (i) secrecy, i.e. 
can someone other than the intended party view the data in transit?, (ii) immutability, i.e. how can one be assured that 
someone has not altered the data in transit?, (iii) authentication, i.e. how can one ensure that each party in the con- 
versation, e.g. session, is who it says it is?, (iv) authorization, i.e. is the authenticated party allowed to do what it is 

45 requesting to do?, and (v) non-repudiation, i.e. can a party repudiate its involvement, e.g. its actions?. 

[0008] Secrecy is generally provided by encrypting data. For example, encrypted HTML, i.e. HTML/HTTPS (SSL), 
is used to insure that unintended parties can not see the information as it travels across the network, e.g. the Internet. 
However, this does not prevent the various transit points, e.g. the service provider and the portal, from viewing data 
that travels over the network. Thus, for example, a URL to a payor's detailed bill information could be misappropriated 

so at a transit point or from the payofs terminal, e.g. from the payor's browser history, and could then later be used to 
access the payor's detailed bill information. 

[0009] Like secrecy, immutability is also generally provided by encrypting the data. Typically, due to the nature of 
the algorithms, encryption which provides good secrecy also provides good immutability. For example, HTML/HTTPS 
is used to insure immutability as the data bits are travelling across the network. That is, even if one were to improperly 
55 access data off a network router, or at a transit point, it would be virtually impossible to read the misappropriated data; 
however, the data still could be altered. Thus, for example, an account number associated with the payor's detailed 
bill information could be misappropriated at a transit point and mangled. It this were to occur, the biller would have no 
way of confirming that a payor account number, originally sent by the portal to the payor and then sent by the payor 
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to the biller with the request for detailed bill information, has not been misappropriated and mangled before being 
received by the biller. 

[0010] Figure 1 is a somewhat simplified network diagram indicating various channels which may be established 
between network entities to provide electronic bill presentment services. As shown in Figure 1, the network includes 

5 users A-C which are represented on a network by network devices 1 05A-1 05C. The network devices 1 05A-1 05C could, 
for example be any device capable of communicating over the network, such as a personal computer, palm computer, 
set top box etc. Billers A-C are also represented on the network by network devices 110A-1 1 0C, typically although not 
necessarily high power workstations, mini-computers or mainframe computers, often referred to as servers. The net- 
work also includes an access portal 115 and a service provider 120. 

10 [0011] Users A-C access services available on the network by establishing channels 125A-125C with the access 
portal 1 1 5. The access porta! is linked to the service provider 1 20 by channel 1 30 . The service provider in turn is linked 
to the billers A-C by channels 135A-135C. 

[0012] For example, the channels 125A-125C may be Internet channels which are established through an Internet 
access provider, such as America Online (not shown), using a browser, such as browsers currently available from 

*s Microsoft Corporation and Netscape Corporation. Accordingly, the communications between the user devices 105A- 
105C and the access portal 115 are typically encrypted HTML communication, i.e. HTML/HTTPS. 
[0013] Communications between the access portal 115 and the service provider 120 typically will follow a protocol 
such as I FX, or OFX etc., which may better ensure the security of the communications whether the link is via a private 
network or a public network such as the Internet. Similarly, communications between the service provider 120 and the 

20 biller network devices 11 OA- 11 0C will also typically follow an established protocol and be transmitted via channels 
135A-135C which are provided on a private or public network. 

[0014] If detailed bill information is desired by a user, further communications channels must be established between 
the requesting user and the appropriate biiler. Accordingly, if user A desires detailed billing information relating to the 
bills of billers A-C communication links 140A-140C will be required as shown in Figure 1. These communication links 

25 will typically be established via the Internet using an Internet browser and accordingly carry encrypted HTML commu- 
nications. It will be recognized that channels similar to channels 140A-1 40C could be established between user devices 
1 05B and 1 05C and biller devices 1 1 0A-1 1 0C to communicate detailed bill information from billers A-C to users B and C. 
[0015] Each of the users A-C will typically be known to different network entities by different identifiers. For example, 
as shown in Figure 2, each of the users A-C are known to each of the billers A-C by the user's name, e.g. A, B or C, 

30 the applicable user's address, e.g. ZA, ZB orZC, and a unique account number, e.g. AA-CC which each biller associates 
with each user. 

[0016] The access portal 1 15 will typically know each of the users A-C by a unique user name, e.g. A'-C and a unique 
password, e.g. PA-PC. Alternatively, users may be known to the access portal 115 by a digital certificate, e.g. a digital 
signature, although this is relatively uncommon today. 

35 [001 7] The user name and password or digital certificate are often referred to as the user's credentials and are used 
by the access portal 1 15 to authenticate the user. The access portal 115 then vouches for authenticated users to other 
network entities. Should a particular user also have a transactional relationship with the access portal, for example if 
the access portal is a user's financial institute or stock brokerage firm, the user will also typically be known to the access 
portal by additional information similar to that shown in the biller columns of Figure 2. 

40 [0018] Figure 3A depicts typical communications between and functions of various network entities in providing bill 
summary information to a requesting user. As shown, network device 1 05A, representing user A, implements a browser 
305, typically stored on a local memory, to communicate its credentials via an encrypted HTML communication over 
the Internet channel 125 A to the access portal 115. The access portal 115 processes the credentials to authenticate 
user A, as indicated by reference numeral 310. Portal 115 then provides a response , as represented by the commu- 

45 nicated authentication message, to network device 105A either granting or denying access based on whether or not 
user A has been successfully authenticated by the processing of the credentials. If access is granted, user A, operating 
network device 105A, may now request bill summary information from the access portal 115 via the channel 125A. 
[0019] Having authenticated user A, the access portal 115 transmits the request for bill summary information via a 
protocol over channel 130 to the service provider 120. In response to the request, the service provider 120 retrieves 

so the bill summary information and applicable universal resource locators (URL's) 31 5 from, for example, a local memory. 
The bill summary information and URL's 315 are typically provided by the billers via protocol or batch transmissions 
over channels 135A-135C to the server 120 offline, i.e. in non-real time, with respect to the user request for the bill 
summary information. 

[0020] The bill summary information and URL's are provided over channel 130 from the service provider 120 to the 
55 access portal 115. The access portal 1 1 5 then directs the bill summary and associated URL's to the user Internet device 
105A via the Internet channel 125A in an encrypted HTML message. 

[0021] Accordingly, bill summary information and URL's flow via a protocol from the biller to the service provider and 
from the service provider to the access portal. The bill summary information is only provided by the access portal to 
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the user after authentication of the user. Further, the bill summary information and associated URL's for a particu ar 
user are provided to the access portal for transmission to the requesting user only if the access portal can vouch for 
the user to the service provider based upon its authentication of the user. 

[00221 The URL's associated with the bill summary information represent the addresses to the bill detail information 
stored on the network 1 00 for the transmitted summarized bill information. The bill detail information of billers A-C may 
be respectively stored, for example, on the memories 320A-320C. It should be recognized that, as described m the 
above-referenced related applications, the bill detail information could also or alternatively be stored at ^ service 
provider 120 or at another network site controlled, for example, by a bill aggregator. In any event, *e URL. to the bill 
detail information are passed, along with the bill summary information, from the service provider 120 to the access 
portal 115 and from there to the user network device 1 05A. Typical* each URL is embedded as a hyperiink in the 
applicable bill summary information presentation which will appear on a display included in the network device 1 05A^ 
[0023] Atypical display is shown in Figure 4. Figure 4 depicts a display 400 of network device 105A which is used 
to present the requested bill summary information for user A. As shown, the presentation includes the names of billers 
A-c7n display areas 405A-405C, the applicable bill amounts XA-XCbilled by each of the billers A-C to user Am display 
areas 410A-410C and a view bill request area associated with each of the billers A-C in display areas 415A-415C 
which can be clicked on using a mouse or other input device to activate the applicable hyperlink URL HA-HC, identified 
with reference numerals 420A-420C, to establish a link to the bill detail information underlying the bill summary ^for- 
mation being presented. The applicable bill may also be paid direct* from the bill summary presentation by clicking 

reference numeral 420A in Figure 4, the user network device 1 05A is linked via an encrypted HTML Internet channel 
140A to the biller address, i.e. URL address HA, at which the detailed bill information of the biller A for user A is stored. 
The detailed bill information is then provided via the channel 140A to the user A network device 105A with ou either 
the request or the provided detailed bill information flowing through the service provider 1 20 or access portal 11 5. 
[0025] It should be understood that, if the bill detail information were stored at the service provider 1 20 or anaggre- 
qator (not shown), the hyperlink would link directly to an address at the aggregator or service provider network s,te at 
which the requested detailed bill information is maintained. In any event, the access portal 115 does not vouch for user 
A to biller A the aggregator, or the service provider 120 in connection with the bill detail request and the bill detail 
information is communicated to the user A from biller A, the aggregator or the service provider 120 without flowing 
30 through the access portal 115. 

[0026] This lack of authentication by the access portal 1 15 in connection with the bill detail request from user A is 
sometimes referred to as "the problem of transitive authentication". To address this problem it has been proposed to 
implement an OFX protocol (i.e. Open Financial Exchange Specification 1.51 dated November 23, 1995. www.OFX. 
net) such that the creator of the bill detail information, e.g. the biller, aggregator or service provider etc., create a 

35 somewhat extended URL. 

[0027] As shown in Figure 5A, in the proposed implementation of OFX 1 .51 , the somewhat extended URL 500 in- 
cludes a network address 505 for the bill detail information, a bill identification (ID) 510 which identifies the particular 
bill being requested, and a user account number 51 5 which the biller associates with the applicable user. As ind.cated 
in Figure 5A, the bill ID and user account number are typically encrypted, but may instead be hashed. 

40 [0028] Figure 5B presents a more realistic depiction of the somewhat extended URL 500 of Figure 5A for a typical 
Internet address prior to encrypting or hashing the bill ID 51 0 and user account number 51 5. More particularly, Figure 
5B depicts the somewhat extended URL 500' with the network address 505'. the bill ID 510' and the account number 
515* 

[0029] The somewhat extended URL 500' provides the recipient of the request for detailed bill information, e.g. the 
45 biller, bill aggregator or service provider, with sufficient information to identify the particular bill based on the bill ID 51 0' 
and to verify the user account number based on account number 51 5\ prior to allowing access to the detailed bill 
information stored at address 505'. However, the recipient has no way of verifying that the request has actually been 
made by the appropriate user, for example user A as shown in Figure 3B. Furthermore, there is no way for the recipient 
to know whether the somewhat extended URL originally transmitted by the access portal 115 has been tampered with 
so and, for example, includes modified e.g. mangled, address, bill ID and/or user account number information. 

[0030] For example, it is impossible for the recipient to know if the somewhat extended URL has been improperly 
copied from the user's browser either by operation of the user's network device on which the somewhat extended U RL 
may be stored, by hacking into the information stored on the user's network device by the browser, or by installing 
coding, such as a JAVA applet, which automatically transmits information stored on the user's network device without 
55 user's knowledge to a network device under the control of others. It is also impossible for the recipient to know if the 
encrypted data has been altered. Hence, the proposed implementation of OFX 1 .51 cannot ensure the integrity of the 
somewhat extended URL or serve as an aid in authenticating to the recipient that the requester is who he/she says 
he/she is. 
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[0031 J Accordingly, a need remains tor a technique to address the problem of transitive authentication. 
Objectives of the Invention 

5 [0032] Accordingly, it is an objective of the present invention to address the problem of transitive authentication. 
[0033] It is another objective of the present invention to provide a technique which protects the integrity of the URL's 
which are used to access private information over a network. 

[0034] It is also an objective of the present invention to provide a technique which allows a request recipient to 
authenticate the requesting party. 

10 [0035] Additional objects, advantages, novel features of the present invention will become apparent to those skilled 
in the art from this disclosure, including the following detailed description, as well as by practice of the invention. While 
the invention is described below with reference to a preferred embodiment(s), it should be understood that the invention 
is not limited thereto. Those of ordinary skill in the art having access to the teachings herein will recognize additidnal 
implementations, modifications, and embodiments, as well as other fields of use, which are within the scope of the 

is invention as disclosed and claimed herein and with respect to which the invention could be of significant utility. 

Summary Disclosure of the Invention 

[0036] In accordance with the invention a networked system for accessing information includes a first network station, 

20 such as a network server or other network device, which represents a first network entity, for example a biller. A second 
network station, which could be another network server or some other network device, represents a second network 
entity, such as an access portal, and controls access to the network by a third network entity. The first station controls 
access to information, such as detailed bill or other information, stored on a network for the third network entity, such 
as a customer of the biller. The first station encrypts a first component message, sometimes simply referred to as a 

25 first component of an aggregate message, with a first crypto-key associated with the first network entity, e.g. the biller. 
[0037] The first crypto-key could be a symmetric crypto-key which is known only to the first network entity. Alterna- 
tively, the first crypto-key could be a non-symmetric crypto-key, such as a public crypto-key of a joint private-public 
crypto-key pair associated with the first network entity. In any event, beneficially the first network station encrypts the 
first component message offline, i.e. in non-real time. That is, preferable the first network station encrypts the first 

30 component message at a time other than the time of a request, such as a request for bill summary information, which 
will be responded to by transmitting the encrypted first component message. The first component message preferably 
includes identity information associated with the third network entity, and integrity information which corresponds to 
the identity information. The identity information advantageously includes an identification of information stored on the 
network, such as a bill ID and/or an account number. The integrity information could, for example, include a hash of 

35 the identity information. In a typical implementation, the first network station combines the encrypted first component 
message with a network address for the stored information. 

[0038] The integrity information provides enhanced immutability, by ensuring that the first network entity can verify 
that a returned first component message has not been mangled or otherwise altered. For example, if the first component 
message includes a bill ID and payor account number which is returned to the biller by the payor with the request for 
40 detailed bill information, the biller can use the integrity information to verify that the returned bill ID and account infor- 
mation are the same bill ID and account number included in the first component message. 

[0039] The second network station encrypts a second component message with a second crypto-key and combines 
the encrypted first and the encrypted second component messages. The combined messages are then transmitted 
over the network, which could for example be the Internet. It would be recognized by those skilled in the art that the 
45 second crypto-key could, if desired, also be applied to the encrypted first component message at the time of encrypting 
the second component message. 

[0040] The second crypto-key could be a non-symmetric crypto-key. The non-symmetric crypto key might, for ex- 
ample, be a private crypto-key of a joint private-public crypto-key pair associated with the second network entity. Al- 
ternatively, the second cryptokey could be a symmetric crypto-key known also to the first network entity. In any event, 

so preferably the second network station encrypts the second component message and combines the encrypted first and 
the encrypted second component messages on-line, i.e. in real time. That is, the second network station beneficially 
encrypts the second component message and combines it with the encrypted first component message at the time of 
a request, e.g. a bill summary request, which will be responded to by transmitting the combine component messages. 
[0041] The second component message preferably includes voucher information which indicates that the second 

55 network entity has authenticated the third network entity. The voucher information enhances authentication by allowing 
the second network entity to vouch for the third network entity to the first network entity. The voucher information can 
be used to authenticate who the third network entity is and, if desired, the third network entity's relationship with the 
second network entity. This allows, for example, a portal to confirm to a biller that the payor requesting detailed bill 
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information is who he/she says he/she is and that the payor has a relationship with the portal. 
[0042] Advantageously, the second component message also includes a timestamp corresponding to a time at which 
the combined messages are transmitted by the second network station . The timestamp enhances secrecy by preventing 
a misappropriated combined messages from later, i.e. beyond some designated time period after the time indicated 

5 by the timestamp, being used to access the information, such as detailed bill information. The timestamp also enhances 
non-repudiation, since it can be used by the first network entity to confirm that the combined messages were recently 
transmitted by the second network entity to the third network entity. Thus, for example, the timestamp can be used by 
a biller to confirm that a request for detailed bill information was received promptly after the associated bill summary 
information had been provided by a portal to the applicable payor. 

10 [0043] A third network station, such as a personal computer or other network device, represents the third network 
entity and receives the transmitted combined messages, or what might also be referred to as an aggregate message 
formed of combined component messages. The third station further transmits the received combined messages over 
the network in order to obtain access to the stored information. In this regard, the first network station receives the 
further transmitted combined messages, and decrypts the encrypted first and the encrypted second component mes- 

15 sages contained therein. The first network station then controls access by the third network station to the stored infor- 
mation based on the decrypted first and second component messages. For example, if the first station is unable to 
successfully decrypt either of the component messages, access would typically be denied. If the decrypted first com- 
ponent message is associated with an entity different than the entity being vouched for in the second component 
message access would also be denied. If the timestamp indicates that a threshold time period has expired since the 

20 second network station transmitted the combined message, access may be denied. 

[0044] In accordance with other aspects of the invention, a fourth network station, such as another server or network 
device, represents a fourth network entity, for example a service provider. The fourth network device encrypts a third 
component message with a third crypto-key and initially combines the encrypted first and third component messages. 
The fourth network station then transmits the initially combined messages over the network. 

25 [0045] The third crypto-key could be a non-symmetric crypto-key, which, for example, might be a private crypto-key 
of a joint private-public crypto-key pair associated with the fourth network entity. Alternatively, the third crypto-key could 
be a symmetric crypto-key known also to the first network entity. In any event, preferably the fourth network station 
encrypts the third component message and combines the encrypted first and the encrypted third component messages 
on-line i e in real time. That is, the fourth network station advantageously encrypts the third component message and 

30 combines it with the first component message at the time of a request, e.g. a bill summary request, which will be 
responded to by transmitting the combined messages. The public crypto-keys associated with the second and fourth 
network entities, could be distributed by either one of these entities, or by each of these entities, or by some other 
network entity. 

[0046] The third component message preferably includes relationship information which indicates that the identity 
35 and integrity information was received by the fourth network entity from the first network entity and transmitted by the 
fourth network entity to the second network entity. 

[0047] The second network station receives the transmitted initially combined messages, and combines the encrypt- 
ed first and the encrypted third component messages contained therein with the encrypted second component message 
to create the above described combined messages. Hence, the first network station can decrypt the encrypted third 
40 component message and also use this message to control access by the third network station to the stored information. 
For example, if the information in the third component message is inconsistent with that in the second component 
message, access will be denied. 

[0048] it should be understood that as used herein, the network could be made up of multiple sub-networks, some 
of which could be public while others are private. For example, in a bill presentment and payment implementation, the 
45 first and third network stations and the second and third network stations might communicate over the Internet, while 
the fourth network station communicates with the first network station via the Internet or some other network, and with 
the second network station over the Internet or some still further network. 

[0049] In accordance with other aspects of the invention, an electronic message has a first component created by 
a first network entity and encrypted with a first crypto-key, associated with the first network entity, such that the encrypted 

so first component can be decrypted by only the first entity. The message also includes a second component created by 
a second network entity, and encrypted with a second crypto-key, such that the encrypted second component can also 
be decrypted by the first network entity. In some implementations, the message may advantageously additionally in- 
clude a third component created by a third network entity and encrypted with a third crypto-key, associated with the 
third network entity, such that the encrypted third component can be decrypted by the first network entity. 

55 [0050] According to further aspects of the invention an electronic message, includes a first component encrypted 
with only a symmetric crypto-key and a second component, different than the first component, encrypted with only a 
non-symmetric crypto-key. In certain implementations the symmetric crypto-key is associated with a first entity, and 
may only be known to the first entity, while the non-symmetric crypto-key is associated with a second entity. The non- 
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symmetric crypto-key may beneficially be a private crypto-key of a joint private-public crypto-key pair associated with 

the second entity. t . . /IIDn 

[0051] In accordance with still other aspects of the invention, an extended network universal resource locator (URL) 
which is particularly suitable for Internet commerce includes a first component having a network address at which 

5 stored information can be accessed on a network. The extended URL also includes a second component having identity 
information associated with a first network entity and an integrity value corresponding to the identity information. The 
second component is encrypted with a first crypto-key of a second network entity. The extended URL additionally 
includes a third component having relationship information indicating that the encrypted second component was re- 
ceived by a third network entity from the second network entity and transmitted by the third network entity to a fourth 

10 network entity. The third component is encrypted with a second crypto-key of the third network entity. The extended 
URL further includes a fourth component having voucher information indicating that the fourth network entity has au- 
thenticated the first network entity and that transmission of the extended URL by the fourth network entity to the first 
network entity occurred at a particular time. The fourth component is encrypted with a third crypto-key of the fourth 

network entity. . . .... 

is [0052] For example, if the extended universal resource locator is implemented in connection with electronic bill pre- 
sentment via the Internet, the stored information could be detailed bill information. The network address would be an 
Internet URL The identity information could include an identification of the stored information, e.g. detailed bill infor- 
mation and an account number associated with the first network entity. Preferably, the integrity value is a hash of the 
identity information and the transmission time information is a timestamp. 

20 [0053] In such an implementation, the second network entity might be a biller or other entity which controls access 
to the stored information, such as the detailed bill information. The third network entity, might be a service provider, 
such as CheckFree Corporation, which controls access to other information, such a summary bill information, which 
is transmitted with the extended network universal resource locator by the fourth network entity to the first network 
entity, which might be the customer. The fourth network entity might an access portal which controls access by the first 

25 network entity to other entities on the network. 

Brief Description of Drawings 

[0054] Figure 1 depicts a conventional bill presentment network. 
30 [0055] Figure 2 depicts the user identification information conventionally available to the access portal and the billers 
of Figured 1. 

[0056] Figure 3A depicts a typical message flows between a user, the access portal, the service provider and a biller 
to request and present bill summary information via the Figure 1 network. 

[0057] Figure 3B depicts a typical message flows between and a user and a biller to request and present detailed 
35 bill information via the Figure 1 network. 

[0058] Figure 4 depicts a conventional presentation of bill summary information to the user shown in Figure 3A. 
[0059] Figure 5A depicts a conventional URL for use by the user shown in Figure 3B in requesting detailed bill 
information. 

[0060] Figure 5B is a more realistic depiction of the URL of Figure 5A. 
40 [0061] Figure 6 depicts message flows between a user, the access portal, the service provider and a biller to request 
and present bill summary information via the Figure 1 network in accordance with the present invention. 
[0062] Figure 7 depicts a portion of the collaboratively manufactured extended URL for use in requesting detailed 
bill information as shown in Figure 6, in accordance with the present invention. 

[0063] Figure 8 depicts another portion of the collaboratively manufactured extended URL for use in requesting 
45 detailed bill information as shown in Figure 6, in accordance with the present invention. 

[0064] Figure 9 depicts a combination of summary bill information and the portions of the collaboratively manufac- 
tured extended URL shown in Figures 7 and 8, in accordance with the present invention. 

[0065] Figure 1 0 depicts still another portion of the collaboratively manufactured extended URL for use in requesting 
detailed bill information as shown in Figure 6, in accordance with the present invention. 
so [0066] Figure 1 1 depicts a combination of summary bill information and the collaboratively manufactured extended 
URL, in accordance with the present invention. 

Best Mode for Carrying out the Invention 

55 [0067] Although the present invention will now be described in the context of bill presentment, it should be recognized 
that the invention has wide applicability and can be easily adapted for use in obtaining virtually any type of private 
information by a user directly from the custodian of that information. For example, the present invention may have 
significant application in web banking, web brokerage, web mortgaging, request for credit reports, etc. without requiring 
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the userto sign-on with other than its access portal during the session, even though the user will access the information 
directly from an entity other that the access portal during the session. 

[0068] Figure 6 depicts typical communications between and functions of various network entities in providing bill 
summary information to a requesting user with a collaboratively manufactured extended URL As shown, and previously 

5 described with reference to Figure 3A, network device 105A representing user A implements a browser 305 to com- 
municate its credentials via an encrypted HTML communication over the Internet channel 125A to the access portal 
115. The access portal 115 processes the credentials to authenticate user A as indicated by reference numeral 310, 
and provides a response, as represented by the communicated authentication message, to network device 1 05A either 
granting or denying access based on whether or not User A has been successfully authenticated by the processing of 

io the credentials. If access is granted, user A, operating network device 1 05A, can now request bill summary information 
from the access portal 115 via the channel 125A. 

[0069] Having authenticated user A, the access portal 1 1 5 transmits the request via a protocol over channel 1 30 to. 
the service provider 120. As described above with reference to Figure 5, in accordance with OFX 1.5 the URL 500 
conventionally provided to the service provider 120 from the biller includes a network address (NA) for the bill detail 
15 information 505, a bill ID (BID) 510 which identifies a particular bill being requested and the account number (AN) 515 
which the biller associates with the applicable user. 

[0070] As shown in Figure 7, in accordance with the present invention, the biller performs a hash computation, H, 
on the network address (NA) 505 for the bill detail information, the bill ID (BID) 510 which identifies a particular bill 
being requested and the account number (AN) 515 which the biller associates with the applicable user to form an 
20 integrity value (IV) 520 as follows: 

H[NA + BID + AN] (1) 

25 [0071] The bill ID 510, user account number 515 and the integrity value 520 are then encrypted using a symmetric 
encryption key E to form an encrypted message as follows: 

NA + E [BID+AN+IV] (2) 

30 

[0072] It should be understood that, if desired, the encryption could be performed using the billets non-symmetric 
public key of a joint private/public key pair, in lieu of the symmetric key E. In either case, the encryption and integrity 
value ensure the integrity of the base data, i.e. the bill ID 51 0 and the user account number 515, and the identification 
of the applicable user, in this case user A. The encrypted integrity value provides enhanced protection against altering 
35 of the information which will be returned to the biller by the payor with the request for detailed bill information. Hence, 
the biller can be confident that the exact bill ID, account information and user identification sent to the user is returned 
with user's the request for detailed bill information. 

[0073] As also shown in Figure 7, in accordance with the present invention, the encrypted bill ID 510, user account 
number 515 and integrity value 520 are also signed using a digital certificate S(1), preferably supplied by the service 
40 provider 120 but which could alternatively be supplied by a separate certificate authority, to form an encrypted, signed 
extended URL message 700 to the detailed bill information as follows: 

NA + [E[BID+AN+IV]]S(1) (3) 

45 

[0074] The bill summary information (BSI) and the encrypted, signed extended URL message 700 are provided by 
each biller A-C, preferably via a secure protocol or batch communication over channels 135A-135C, to the service 
provider 120 in a message 315' as the following: 

50 BSI + NA + [E [BID+AN+IV]]S(1) (4) 

Hence, responsive to the request from the access portal 115, the service provider 120 can retrieve, for example from 
a local memory, the applicable message (s) 315*. 
55 [0075] Continuing with the collaborative manufacture of the extended URL which will ultimately be returned to the 
user requesting the bill information, the service provider 120 creates, either prior to, i.e. off-line, or at the time of the 
request for the bill summary information, i.e. on-line, an encrypted, signed relationship certification (RC) BOO, as shown 
in Figure 8. The relationship certificate includes a certification 81 0 that the service provider 1 20 received each of the 
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applicable encrypted, signed extended URL messages 700 from the applicable biller A-C and a certification 820 that 
the service provider 120 is delivering the applicable encrypted, signed extended URL messages 700 to the access 
portal 115. The access portal 115 may, for example under the OFX protocol, be identified to the service provider 120 
in the request for bill summary information received by the service provider 120 from the access portal 115. 
s [00761 As shown in Figure 8, the relationship certificate is encrypted, using the service provider's 120 non-symmetnc 
private key, PKSP(2), of its joint private key PKSP (2)/public key PUBKSP(2) pair, and digitally signed using the service 
provider's 1 20 digital certificate S(2). Thus the encrypted, signed relationship certificate will take the form of a message 
such as the following: 

10 [[RC] PKSP (2)]S(2) ( 5 ) 

The encrypted relationship certificate will ensure that the commercial parties, i.e. the service provider 120 and the 
access portal 115, are identified in the extended URL. 
is [0077] As shown in Figure 9, the bill summary information 910 and a further extended URL message, including the 
encrypted, signed extended URL message 700 and the encrypted, signed relationship certificate 800, are transmitted 
over channel 130 from the service provider 120 to the access portal 115 in a further extended message 900 in the 
following form: 

20 BSI + N A + [E[BID+AN+I VJJS(1 ) + [[RC] PKSP (2)]S(2) (6) 

it should be recognized that the message 900 may be created and stored by the service provider 1 20 prior to receiving 
a request for the bill summary information or created in response to the receipt of such a request 
25 [0078] After receipt of message 900, the access portal 1 1 5 may, if desired verify that message 900 is from the service 
provider 120 and intended for the access portal 115 by applying the public key PUBKSP(2) of service provider 120 to 
the encrypted relationship certificate as follows: 



30 



40 



45 



50 



55 



[[RC]PKSP(2)]PUBSP(2) (7) 



[0079] The access portal 115 continues the collaborative manufacture of the still further extended URL which will 
ultimately be returned to the user requesting the bill information. In this regard, the access portal 115 creates a voucher 
(V) 1005, depicted in Figure 10, which identifies the access portal 115 and indicates that the access portal 115 has 
35 authenticated the user, in this case user A. The access portal 115 then encrypts, using the access portal's 115 non- 
symmetric private key, PKAP(3), of its joint private key PKAP(3)/public key PUBKAP(3) pair, and signs, using a digital 
certificate, S(3), provided by the service provider 120 or some other certificate authority, the voucher (V) 1005 and a 
time stamp (TS) 1010 to form an encrypted, signed voucher record (VR) 1000 as follows: 



[[V+TSlPKAP(3)]S(3) ( 8 ) 

The encrypted, signed voucher will ensure that it can be verified that the applicable user is known to the access portal 
115, and the encrypted, signed timestamp will ensure that the bill detail request has only a limited lifetime. 
[0080] More particularly, the voucher enhances authentication. That is, the voucher, which will be transmitted by the 
portal to the user with the bill summary information and by the user to the biller with the request for detailed bill infor- 
mation as will be described further below, serves as the portal's confirmation to the biller that the payor is in fact who 
he/she says he/she is and that the payor has a relationship with the portal. 

[0081] The timestamp enhances secrecy and non -repudiation by preventing the network address 505 in the collab- 
oratively manufacture extended URL 1150 from being used to access the user's detailed bill information after a short 
timeout, i.e. threshold, period, e.g. 30 minutes from the transmission of the extended URL 1 1 50 by the portal. Although 
not foolproof, since the timestamp prevents a misappropriated network address 505 from being used to access detailed 
bill information after a relatively short period of time, the likelihood that a request to access detailed bill information 
from some misappropriating party will be granted, is significantly reduced. Furthermore, because the timestamp evi- 
dences that the bill summary information associated with the now requested detailed bill information was recently, i.e. 
within the timeout period, transmitted to the user by the portal, it is more difficult for the user to repudiate its receipt of 
the bill summary information and/or of its request for access to the detailed bill information. 

[0082] The bill summary information and the still further extended URL 1150, including the encrypted, signed ex- 
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tended URL message 700, the encrypted, signed relationship certification 800, and the encrypted, signed voucher 
record 1000, are transmitted as the following message, depicted as message 1100 in Figure 11 , over encrypted html 
channel 1 30, from the access portal 1 1 5 to the requesting user, here user A being represented by network device 1 05A: 



BSI + NA + [E[BID+AN+IV]]S(1) + [[RC]PKSP(2)]S(2) + 

[[VR]PKAP(3)]S(3) (9) 

10 It will be recognized that encrypted html channels are often referred to as https or secure socket layer (SSL) channels. 
[0083] Accordingly, the access portal 115 directs to the user network device 105A, via the channel 125A in an en- 
crypted HTML message, a message 1100 having a very rich, collaboratively manufactured extended URL 1150 includ-- 
ing: 

is (i) the encrypted, signed extended URL message 700 generated by the biller with the unencrypted network address, 

NA, 505 at which the bill detail information is stored and the encrypted, signed bill identification, BID, 510, user 
account number, AN, 515, and integrity value, IV, 520, 

(ii) the encrypted, signed relationship certification, RC, 800 generated by the service provider 120 which certifies 
that the encrypted signed extended URL message 700 was received from the applicable biller A-C and delivered 

20 to the applicable access portal 115, and 

(iii) the encrypted, signed voucher record, VR, 1 000 generated by the access portal with the voucher 1 005 certifying 
that the access portal 1 1 5 has provided the collaboratively manufactured extended message 1 1 00 to the applicable 
user, in this case user A, and the time stamp 1010. 

25 [0084] With the collaboratively manufactured extended URL 1150 of message 1100, as shown in Figure 11 , substi- 
tuted for the URL 500 shown in Figure 5, the display 400 of Internet device 105A presents, as shown in Figure 4, the 
requested bill summary for user A. The presented bill summary includes a view bill request area associated with each 
of the billers A-C in display areas 415A-C. The view bill request area can be clicked on using a mouse or other input 
device to activate the applicable collaboratively manufactured extended URL 1150 forwarded in message 1100 to 

30 hyperlink to the bill detail information underlying the applicable bill summary information being presented, as previously 
described with reference to Figure 3B. Thus, by clicking on view bill area 41 5A and thereby activating the collaboratively 
manufactured extended URL 1150 to the bill detail for biller A's bill, the user network device 105A is linked via an 
encrypted HTML channel 140A to the address at which the detailed bill information of the biller A for user A is stored 
as described with reference to Figure 3B. 

35 [0085] However, before the detailed bill information is provided via the channel 140A to the user A network device 
105 A, the biller checks the signature S(1) on the encrypted bill ID 510, user account number 515 and integrity value 
520, and decrypts, using the corresponding symmetric decryption key D or the billers non-symmetric private key, as 
applicable, the bill ID 510, user account number 51 5 and integrity value 520 as follows: 



40 



50 



55 



D[BID+AN+IV] (10) 



[0086] The biller verifies the decrypted bill ID 510 and user account number 515 and, using the integrity value 520, 
also verifies that this information was the same information which it originally forwarded to the service provider 120. 
45 [0087] Further, the biller checks the signature and then decrypts the encrypted relationship certificate using the public 
key, PUBKSP(2), of the service provider 120 as follows: 

[[RC]PKSP(2)]PUBKSP(2) (11) 



The biller, using the relationship certificate, verifies that the service provider 120 received the bill ID 51 0, user account 
number 515 and integrity value 520 from the applicable biller and forwarded this information to the access portal 115. 
[0088] Further still, the biller checks the signature and then decrypts the encrypted voucher record using the public 
key, PUBKAP(3) of the access portal 115 as follows: 

[[VR]PKAP(3)]PUBKAP(3) (12) 
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The biller using the voucher record, verifies that the access portal 115 identified in the relationship statement of the 
service provider 120 vouches for the applicable user, and that, based on the time stamp, the time penod within which 
the request for detailed bill information has been received Is within a designated threshold, preferably two to five mm- 

[00891 Hence, not only is bill summary information transmitted via a secure protocol from the biller to the service 
provider and from the service provider to the access portal, but the bill summary information is not transmitted until 
after the applicable user is authenticated by the access portal. Further, the bill summary information for a partcular 
user is provided to the access portal for transmission to the requesting user only if the access portal 115 can vouch 
for the user to the service provider 1 20 based upon its authentication of the user. Moreover, the collaboratively man- 
ufactured extended URL 1150 provides the request recipient, e.g. the biller, bill aggregator or service provider etc., 
information necessary to identify the particular bill and verify the user account number prior to allowing access to the 

detailed bill information. . - 

[0090] Additionally, using the above described technique, the recipient now has a way of venfying that the request 
has actually been made by the appropriate user, for example user A as shown in Figure 6. More particularly, the 
collaboratively manufactured extended URL 1150 provides the recipient with the ability to verify that the information 
originally transmitted by the access portal has not been tampered with and hence, reflects the correct network address 
bill ID and user account number information. Further, the collaboratively manufactured extended URL 1150 makes it 
possible for the recipient to determine if the information has been improperly copied from user A's browser. Hence, by 
collaborative manufacture the integrity of the information and authenticity of the requesting party can be ensured. 
[00911 As described above, the present invention addresses the problem of transitive authentication. Further, the 
present invention provides a technique which protects the integrity of the URL's which are used to access private 
information over a network. Additionally, the present invention provides a technique which allows a URL to be utilized 
by a request recipient to authenticate the requesting party. 

[0092] It will also be recognized by those skilled in the art that, while the invention has been described above in terms 
25 of one or more preferred embodiments, it is not limited thereto. Various features and aspects of the above described 
invention may be used individually or jointly. Further, although the invention has been described in the context of its 
implementation in a particular environment and for particular purposes, e.g. creating extended URL's, those skilled in 
the art will recognize that its usefulness is not limited thereto and that the present invention can be beneficially utilized 
in any number of environments and implementations. Accordingly, the claims set forth below should be construed .n 
30 view of the full breadth and spirit of the invention as disclosed herein. 
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Claims 

as 1 . A networked system for accessing information, comprising: 

a first network station, representing a first network entity, configured to control access to information stored 
on a network for a third network entity, and to encrypt a first component message with a first crypto-key as- 
sociated with the first network entity; 
40 a second network station, representing a second network entity, configured to control access to the network 

by the third network entity, to encrypt a second component message with a second crypto-key, to combine the 
encrypted first and the encrypted second component messages, and to transmit the combined messages over 

the network; and . 
a third network station, representing the third network entity, configured to receive the transmitted combined 
« messages and to further transmit the received combined messages over the network in order to obtain access 

to the stored information; 

wherein the first network station is further configured to receive the further transmitted combined messages, 
to decrypt the encrypted first and the encrypted second component messages in the received further trans- 
mitted combined messages, and to control access by the third network station to the stored information based 
so on the decrypted first and second component messages. 

2. A networked system according to claim 1 , wherein: 

the first crypto-key is a symmetric crypto-key; and 
55 the second crypto-key is a non-symmetric crypto-key. 

3. A networked system according to claim 2, wherein: 

the symmetric crypto-key is known only to the first network entity. 
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4. A networked system according to claim 2, wherein; 

the non-symmetric crypto-key is a private crypto-key of a joint private-public crypto-key pair associated with 
the second network entity. 

5. A networked system according to claim 1 , wherein: 

the first crypto-key is a first non-symmetric crypto-key; and 

the second crypto-key is a second non-symmetric crypto-key, different than the first non-symmetric crypto-key. 

6. A networked system according to claim 5, wherein: 

the first non-symmetric crypto-key is a public crypto-key of a joint private-public crypto-key pair associated, 
with the first network entity; and 

the second non-symmetric crypto-key is a private crypto-key of a joint private-public crypto-key pair associated 
with the second network entity. 

7. A networked system according to claim 1 , wherein; 

the first component message includes identity information associated with the third network entity, and integrity 
information which corresponds to the identity information; and 

the second component message includes voucher information which indicates at the second network entity 
has authenticated the third network entity. 

8. A networked system according to claim 1 , further comprising: 

a fourth network station, representing a fourth network entity, configured to encrypt a third component message 
with a third crypto-key, to initially combine the encrypted first and the encrypted third component messages, 
and to transmit the initially combined messages over the network; 

wherein the second network station is further configured to receive the transmitted initially combined messag- 
es, to combine the encrypted first and the encrypted third component messages in the received initially com- 
bined messages with the encrypted second component message to create the combined messages; 
wherein the first network station is further configured to decrypt the encrypted third component message in 
the received further transmitted combined messages, and to control access by the third network station to the 
stored information based also on the decrypted third component message. 

9. A networked system according to claim 8, wherein: 

the first component message includes identity information associated with the third network entity, and integrity 
information which corresponds to the identity information; 

the second component message includes voucher information which indicates that the second network entity 
has authenticated the third network entity; and 

the third component message includes relationship information which indicates that the identity and the integ- 
rity information was received by the fourth network entity from the first network entity and transmitted by the 
fourth network entity to the second network entity. 

10. A networked system according to claim 8, wherein: 

the first crypto-key is a symmetric crypto-key; 

the second crypto-key is a non-symmetric crypto-key; and 

the third crypto-key is a non-symmetric crypto-key. 

11. A networked system according to claim 1 , wherein: 

the second component message further includes a timestamp corresponding to a time at which the combined 
messages are transmitted by the second network station. 

12. A networked system according to claim 1 , wherein: 

the first network station is further configured to combine the encrypted first component message with a network 
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address for the stored information; 

the second network station is further configured to combine the combined encrypted first component message 
and the network address with the encrypted second component message to create the combined messages; 

and , . . , 

5 the first network station is further configured to control access by the third network station to the stored infor- 

mation based on the network address and the decrypted first and second component messages. 

13. A networked system according to claim 1 , wherein: 

to the second network station transmits the combined message in response to a received request; 

the first network station encrypts the first component message prior to receipt of the request by the second 
network station; and . 
the second network station encrypts the second component message and combines the encrypted first and 
the encrypted second component messages after receipt of the request by the second network station. 
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14. A method of creating an electronic message for transmission over a network, comprising the steps of: 



encrypting a first component with a first crypto-key, associated with a first network entity, such that the en- 
crypted first component can be decrypted by only the first network entity; 
20 encrypting a second component with a second crypto-key, associated with a second network entity, such that 

the encrypted second component can be decrypted by the first network station; and 
transmitting the encrypted first component and the encrypted second component as a combined message. 



15. A method according to claim 1 4, wherein: 

the first crypto-key is a symmetric crypto-key; and 
the second crypto-key is a non-symmetric crypto-key. 

16. A method according to claim 1 5, wherein: 



the symmetric crypto-key is known only to the first network entity; and 
the non-symmetric crypto-key is known only to the second network entity. 

17. A method according to claim 1 5, wherein; 

35 the non-symmetric crypto-key is a private crypto-key of a joint private-public crypto-key pair associated with 

the second network entity. 

18. A method according to claim 14, wherein: 

40 the first crypto-key is a first non-symmetric crypto-key; and 

the second crypto-key is a second non-symmetric crypto-key. 

19. A method according to claim 1 8, wherein: 

45 the first non-symmetric crypto-key is a public crypto-key of a joint private-public crypto-key pair associated 

with the first network entity; and 

the second non-symmetric crypto-key is a private crypto-key of a joint private-public crypto-key pair associated 
with the second network entity. 

so 20. A method according to claim 1 4, further comprising the steps of: 

encrypting a third component with a third crypto-key, associated with a third network entity, such that the 
encrypted third component can be decrypted by the first network entity; and 

transmitting the encrypted third component with the encrypted first and the encrypted second components as 
55 the combined message. 

21. A method according to claim 20, wherein: 
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the first crypto-key is a symmetric crypto-key; 

the second crypto-key is a first non-symmetric crypto-key; and 

the third crypto-key is a second non-symmetric crypto-key. 

22. A method according to claim 20, wherein: 

the first component includes identity information associated with a fourth network entity and integrity informa- 
tion corresponding to the identity information; 

the second component includes relationship information which indicates that the identity and the integrity 
information were received by the second network entity from the first network entity and transmitted by the 
second network entity to the third network entity; and 

the third component includes voucher information which indicates that the third network entity authenticated, 
the fourth network entity. 

23. A method according to claim 20, wherein: 

the third component further includes a timestamp corresponding to a time at which the combined message 
is transmitted to the fourth network entity. 

24. A method according to claim 20, further comprising the step of: 

transmitting the encrypted first, the encrypted second and the encrypted third components with a network 
address as the combined message. 

25. A method according to claim 1 4, wherein: 

the combined message is transmitted responsive to a received request; 
the first component is encrypted prior to receipt of the request; and 
the second component is encrypted after receipt of the request. 

26. An electronic message, comprising: 

a first component created by a first network entity and encrypted with a first crypto-key, associated with the 
first network entity, such that the encrypted first component can be decrypted by only the first entity; and 
a second component created by a second network entity, and encrypted with a second crypto-key, such that 
the encrypted second component can be decrypted by the first network entity. 

27. An electronic message according to claim 26, wherein: 

the first crypto-key is a symmetric crypto-key known only to the first network entity; and 
the second crypto-key is a non-symmetric crypto-key. 

28. An electronic message according to claim 27, wherein; 

the non-symmetric crypto-key is a private crypto-key of a joint private-public crypto-key pair associated with 
the second network entity. 

29. An electronic message according to claim 26, wherein: 

the first crypto-key is a first non-symmetric crypto-key; and 
the second crypto-key is a second non-symmetric crypto-key. 

30. An electronic message according to claim 29, wherein: 

the first non-symmetric crypto-key is a public crypto-key of a joint private-public crypto-key pair associated 
with the first network entity; and 

the second non-symmetric crypto-key is a private crypto-key of a joint private-public crypto-key pair associated 
with the second network entity, 

31. An electronic message according to claim 26, further comprising: 

a third component created by a third network entity and encrypted with a third crypto-key, associated with 
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the third network entity, such that the encrypted third component can be decrypted by the first network entity. 

32. An electronic message according to claim 31 ( wherein: 

5 the first component includes identity information associated with a fourth network entity, and integrity informa- 

tion corresponding to the identity information; 

the second component includes relationship information which indicates that the identity and the integrity 
information were received by the second network entity from the first network entity and transmitted by the 
second network entity to the third network entity; and 
10 the third component includes voucher information which indicates that the third network entity has authenti- 

cated the fourth network entity. 

33. An electronic message according to claim 32, wherein: 

the integrity information includes a hash of the identity information. 

15 

34. An electronic message according to claim 32, wherein: 

the third component further includes a timestamp corresponding to a time at which the electronic message 
is transmitted by the third network entity to the fourth network entity. 



20 35. An electronic message according to claim 26, wherein: 

the first component includes identity information associated with a third network entity; 
the second component includes voucher information which indicates that the second network entity has au- 
thenticated the third network entity. 

25 

36. An electronic message according to claim 35, wherein: 

the second component further includes a timestamp corresponding to a time at which the electronic message 
is transmitted by the second network entity to the third network entity. 

30 37. An electronic message according to claim 26, wherein: 

the first network entity controls access to information available on a network; and 
the second entity controls access to other network entities. 

35 38. An electronic message according to claim 26, wherein the first component includes an identification of information 
stored on a network, and further comprising: 

a network address at which the identified stored information can be accessed. 



39. An electronic message, comprising: 

40 

a first component encrypted with only a symmetric crypto-key; and 

a second component, different than the first component, encrypted with only a non-symmetric crypto-key, 

40. An electronic message according to claim 39, wherein: 

45 

the symmetric crypto-key is associated with a first entity; and 
the non-symmetric crypto-key is associated with a second entity. 

41. An electronic message according to claim 40, wherein: 

so the symmetric crypto-key is known only to the first entity. 

42. An electronic message according to claim 40, wherein; 

the non-symmetric crypto-key is a private crypto-key of a joint private-public crypto-key pair associated wil 
the second entity. 

55 

43. An extended network universal resource locator, comprising: 

a first component including a network address at which stored information can be accessed on a network; 
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a second component including identity information associated with a first network entity and an integrity value 
corresponding to the identity information, the second component being encrypted with a first crypto-key of a 
second network entity; and 

a third component including voucher information indicating that a third network entity has authenticated the 
first network entity and that transmission of the extended network universal resource locator by the third net- 
work entity to the first network entity occurred at a particular time, the third component being encrypted with 
a second crypto-key of the third network entity. 

44. An extended universal resource locator according to claim 43, further comprising: 

a fourth component including relationship information indicating that the encrypted second component was 
received by a fourth network entity from the second network entity and transmitted by the fourth network entity to 
the third network entity, the fourth component being encrypted with a third crypto-key of the fourth network enjjty. 

45. An extended universal resource locator according to claim 44, wherein: 

the first crypto-key is a symmetric crypto-key known only to the second network entity; 

the second crypto-key is a first non-symmetric crypto-key associated with the third network entity; and 

the third crypto-key is a second non-symmetric crypto-key associated with the fourth network entity. 

46. An extended universal resource locator according to claim 45, wherein; 

the first non-symmetric crypto-key is one of a private crypto-key and a public crypto-key of a joint private-public 
crypto-key pair associated with the third network entity; and 

the second non-symmetric crypto-key is one of a private crypto-key and a public crypto-key of a joint private- 
public crypto-key pair associated with the fourth network entity. 

47. An extended universal resource locator according to claim 44, wherein: 

the stored information is detailed bill information; 
the network address is an Internet URL; 

the identity information includes an identification of the stored information and an account number associated 
with the first network entity; 

the integrity value is a hash of the identity information; and 
the transmission time information is a timestamp. 

48. An extended universal resource locator according to claim 44, wherein: 

the second network entity controls access to the stored information; 

the fourth network entity controls access to other information which is transmitted with the extended network 

universal resource locator by the third network entity to the first network entity; and 

the third network entity controls access by the first network entity to other network entities. 

49. An extended universal resource locator according to claim 48, wherein: 

the stored information is detailed bill information associated with the first entity; and 
the other information is summary bill information associated with the first network entity. 
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